Codecov Report

❌ Patch coverage is 95.76271% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 89.75%. Comparing base (e4762a0) to head (6e87e47).

@@            Coverage Diff             @@
##             main    #7165      +/-   ##
==========================================
- Coverage   89.82%   89.75%   -0.08%     
==========================================
  Files         276      276              
  Lines       14738    14822      +84     
==========================================
+ Hits        13238    13303      +65     
- Misses       1500     1519      +19     

@cijothomas, could you please check this PR? Especially adding boundaries?

Need to re-run the benchmarks with the latest changes.

Benchmark comparison: main (baseline) vs gh-3428 (candidate) (generated by Claude 🐙)

Benchmarks.Metrics.HistogramExplicitBoundsBenchmarks — BenchmarkDotNet v0.15.8, .NET 10.0.8 (X64 RyuJIT), 13th Gen Intel Core i7-13700H.

TL;DR

• Allocations: unchanged. Every benchmark allocates 0 B on both branches — this change is allocation-neutral.
• Special-case lookups (±Infinity, NaN) are dramatically faster. These now short-circuit instead of scanning the bounds, dropping from ~4–21 ns to well under 1 ns (often ~0).
• General finite-value lookups are ~50% faster at larger bound counts. At BoundCount=49, ExactBoundary / InRangeValue / WithInfiniteBounds all roughly halve (~10.5 ns → ~5.1 ns).
• At small bound counts (10) the general lookups are roughly neutral (within noise; one case ~5% slower).
• ⚠️ BoundCount=50 and BoundCount=1000 comparisons for the finite-value lookups are unreliable — several baseline cells report sub-nanosecond means (e.g. 0.0007 ns, 0.0308 ns), which indicate the JIT eliminated the operation as dead code. The candidate measures real work in those cells, so the apparent "regression" there is a measurement artifact, not a true slowdown. I've excluded those from the conclusions above.

Representative results (.NET 10.0, Mean)

Cases below are where both branches measure real work, so the comparison is sound:

The ±Infinity improvement also holds for the 50 and 1000 bound counts (e.g. LookupNegativeInfinity at 1000/MixedSigned: 3.29 ns → 0.18 ns; LookupPositiveInfinity: 4.13 ns → 0.48 ns) — these baseline cells were not dead-code-eliminated, so they're trustworthy.

Conclusion

A clear performance win with no allocation cost: infinity/NaN edge-case lookups are now effectively free, and the common finite-value lookups are ~50% faster once the bound array is large enough to matter. No genuine regressions were found — the only "slower" numbers come from baseline cells the JIT had optimized away, where the candidate is simply being measured doing real work.

Note: the .NET Framework 4.6.2 rows show the same trend and the same dead-code-elimination artifacts at BoundCount 50/1000.